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1.0  SUMMARY 
1.1  Background 

a.  The  Department  of  Defense  (DOD)  has  developed  and  is  continuing  to 
develop  a  number  of  automated  command,  control,  communication,  and  intelli¬ 
gence  ( C3 I )  systems.  Although  each  of  these  automated  systems  has  a  different 
function  and  a  different  set  of  requirements,  the  automated  systems  all  use 
digital  message  exchange  to  communicate.  Testing  to  verify  that  these  au¬ 
tomated  systems  meet  their  operational  requirements  is  largely  an  exercise  of 
each  system's  software  implementation  as  measured  by  the  output  message 
stream. 

b.  In  the  past,  the  verification  and  validation  of  software  have  been 
accomplished  by  a  highly  individualized  type  of  testing  usually  done  by  the 
software  developers.  Individual  modules  of  software  have  been  tested. 

However,  no  comprehensive  test  methodology  has  been  available  to  verify  the 
functionality  of  the  software  as  a  whole.  This  has  resulted  in  unreliable 
products.  Because  the  U.S.  Army  of  the  1990's  will  depend  upon  the  systems 
developed  now,  an  orderly,  rigorous  testing  methodology  has  been  developed  to 
augment  software  testing. 

c.  The  Test  Item  Stimulator  (TIS)  is  one  type  of  tool  used  for  testing. 
The  Interim  Test  Item  Stimulator  (ITIS)  was  a  test  driver  which  was  developed 
by  the  U.S.  Army  Electronic  Proving  Ground  (USAEPG)  for  development  testing 
(DT)  of  the  Maneuver  Control  System  (MCS).  The  ITIS  has  evolved  into  the  TIS 
to  meet  additional  test  requirements.  Test  conduct  using  the  TIS  is 
separated  functionally  into  three  phases:  pre-test  scenario  preparation, 
real-time  item  stimulation,  and  post-test  data  reduction  and  analysis. 

d.  The  first  phase  is  the  pre-test,  or  the  generation  of  test  cases  that 
will  sufficiently  test  the  system.  To  insure  that  the  critical  and  probable 
paths  will  be  sufficiently  exercised  during  the  real-time  test,  the  test 
director  must  draw  upon  personal  experience  and  understanding  of  the  system 
requirements  to  produce  appropriate  scenarios  and  test  message  scripts. 

e.  The  second  phase  is  the  real-time  test.  This  is  the  conduct  of  the 
test  as  determined  by  the  test  director  in  the  pre-test  phase.  The  TIS  stimu¬ 
lates  the  system  under  test  (SUT)  by  transmission  of  prescripted  messages. 

One  function  of  DT  is  to  determine  how  well  the  SUT  meets  its  performance 
specifications.  Because  of  the  time  criticality  of  the  system  control 
parameters,  this  type  of  action  can  occur  only  in  real  time.  The  results  of 
the  real-time  test  are  recorded  for  use  in  the  third  phase,  the  post-test 
analysis. 


f.  An  in-depth  study  of  the  test  results  is  conducted  during  the 
post-test  analysis  phase.  This  is  the  phase  wherein  the  SUT  performance  is 
measured  against  the  requirements.  The  results  of  this  analysis  will  become 
the  substance  of  a  test  report  for  those  tests  dealing  with  software 
functionality  on  a  system  level. 
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1.2  Objective 


The  Real-Time  Message  Process  Simulation  Capability  investigation  was 
initiated  to  develop  a  method  for  simulating,  in  real-time,  the  responses  of 
controlled  resources  in  testing  message-driven  systems  which  have  control 
functions.  (See  appendix  A.) 

1.3  Summary  of  Procedure 

a.  The  objective  of  this  investigation  was  accomplished  through  three 
steps. 

(1)  Examine  representative  Army  C3I  systems  which  have  real-time  control 
functions  which  cannot  be  tested  using  precomposed  message  streams.  This 
requires  a  review  of  the  1TIS  capability  and  an  exhaustive  look  at  selected 
Army  C3I  system  requirements. 

(2)  Document  those  specific  real-time  processes  that  need  to  be  simulat¬ 
ed,  including  the  inputs  and  outputs  required.  Because  the  implementation  of 
all  processes  is  not  feasible,  all  processes  identified  will  be  documented  and 
the  priority  of  implementing  each  process  will  be  recommended. 

(3)  Provide  input  to  the  requirements  of  the  TIS  that  will  incorporate 
necessary  real-time  processes.  The  TIS  is  a  test  driver  whicluis  evolving 
from  the  ITIS  to  meet  the  testing  requirements  of  the  latest  CJI  systems  such 
as  the  Joint  Tactical  Information  Distribution  System  (JTIDS),  and  the 
Position  Location  Reporting  System/JTIDS  Hybrid  (PJH). 

b.  The  scope  of  this  investigation  was  limited  to  the  already  fielded 
Army  executive  systems,  the  MCS  and  Tactical  Fire  Control  System  (TACFIRE)  of 
the  Fire  Support.  Examination  of  the  Missle  Minder  (TSQ-73)  was  performed  as 
part  of  the  TIS  development. 

1.4  Summary  of  Results 

a.  The  ITIS  Basic  Real-Time  System  (BRTS)  consisted  of  a  design  based 
upon  prescripted  messages  from  an  input  scenario.  Some  real-time  processes 
were  supported  under  the  system  because  they  were  essential  to  the  most  basic 
forms  of  message  exchange. 

b.  Examination  of  documentation  for  the  MCS  and  TACFIRE  systems  showed 
that  each  of  these  systems  contains  processes  which  could  be  defined  as 
real-time  processes.  To  evaluate  these  tactical  systems  and  define 
appropriate  real-time  processing  for  TIS;  three  groups  of  real-time  processes 
were  defined: 

(1)  Required  Processing:  Real-time  processes  in  a  SUT  which  are 
essential  to  message  exchange  and  which  must  be  included  in  the  minimum 
definitions  of  the  System-Specific  Applique  (SSA)  component  of  a  TIS. 

(2)  Desirable  Processing:  Real-time  processing  in  a  SUT  which 
represents  events  that  occur  in  unpredictable  sequences  or  which  may  occur  in 
response  to  unpredictable  outside  events  and  which  should  therefore  be 
included  in  an  SSA  to  test  functions  of  the  SUT  fully. 
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(3)  Scriptable  Processing:  Processing  which  occurs  in  real-time  in  a 
SUT  which  is  predictable  in  sequence  and  content  and  which  may  be  supported  by 
messages  which  can  be  scripted  during  the  pre-test  phase. 

c.  Real-time  processes  identified  in  both  MCS  and  TACFIRE  can  be  placed 
into  each  of  these  categories.  Figure  1  shows  a  comparison  of  the  current  and 
enhanced  MCS  SSA  real-time  processing  with  all  processes  categorized  as 
described  above.  Figure  2  categorizes  TACFIRE  real-time  processes  which  have 
been  identified  during  this  investigation. 

d.  The  International  Standards  Organization  (ISO)  reference  model  shown 
in  figure  3  provides  a  basis  for  comparison  between  diverse  communications 
networks.  Although  some  tactical  systems  have  not  been  designed  with  precise¬ 
ly  defined  functional  layers,  as  suggested  by  the  model,  a  rough  correlation 
may  be  drawn.  Figure  4  shows  this  mapping  of  functional  processes  from  MCS 
and  TACFIRE  to  layers  in  the  ISO  model. 

1.5  Analysis 

Real-time  processes  associated  with  C3I  systems  are  amenable  to 
categorization  by  reference  to  the  ISO  model.  Processes  may  be  further 
described  as  required,  desirable,  or  scriptable.  Processes  from  layers  4 
through  7  of  the  ISO  model  are  generally  supportable  by  prescripting  messages; 
however,  many  of  these  can  be  supported  more  efficiently  by  real-time 
processing. 

1.6  Conclusions 

a.  The  ITIS  MCS  capability  provided  stimulation  with  prescripted 
scenarios.  Enhancements  to  the  real-time  capability  to  provide  verification 
of  future  MCS  capabilities  was  identified. 

b.  The  requirements  for  real-time  process  simulation  for  both  MCS  and 
TACFIRE  have  been  defined  and  are  amenable  to  implementation  in  the  SSA  of 
TIS. 


1.7  Recommendations 

a.  The  present  ITIS  capability  requires  that  all  test  messages  be 
composed  and  validated  prior  to  the  start  of  a  real-time  test.  The  TIS  design 
should  permit  the  stimulus  messages  to  reflect  information  changes  that  a  SUT 
would  expect  in  response  to  its  outputs.  The  situation  that  needs  to  be 
simulated  is  shown  in  figure  5. 

b.  To  support  these  real-time  requirements,  the  TIS  SSAs  should  include 
the  ability  to  expand  and  implement  the  processes  identified  as  required  or 
desirable  in  section  1.4  for  both  MCS  and  TACFIRE. 


PROCESS  CATEGORY 

CURRENT  MCS  SSA  CAPABILITIES 

ENHANCED  MCS  SSA  CAPABILITIES 

ACKNOWLEDGEMENT/RETRY 

ACKNOWLEDGEMENT/RETRY 

REQUIRED 

ERROR  DETECTION  &  CORRECTION  (EDC) 

EDC 

TIME  DISPERSAL  CODING  (TDC) 

TDC 

AUTODIAL* 

DESIRABLE 

AUTOMATIC  RELAY 

END-TO-END  ACCOUNTABILITY 

REMOTE  DBMS  REQUESTS 

SCRIPTABLE 

ABRIDGING 

ABRIDGING** 

*  Requires  additional  hardware 
**  Could  be  supported  by  pre-scripting 

Figure  1.  MCS  Real-Time  Processes 


PROCESS  CATEGORY 

TACFIRE  REAL-TIME  CAPABILITIES 

REQUIRED 

ACKNOWLEDGE/NEGATIVE  ACKNOWLEDGE/RETRY 

EDC 
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SUBSCRIBER  TABLE  MAINTENANCE 

SERIALIZATION  and  VALIDATION 

DESIRABLE 

REMOTE  LOOP  TEST 

MESSAGE  OF  INTEREST  ROUTING 

SYSjFORM  RESPONSE 

SCRIPTABLE 

MESSAGE  COMPACTION 

TACTICAL  EVENT  SIMULATION 

Figure  2.  TACFIRE  Real-Time  Processes 
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TITLE  .  ...  . 

Physical  Layer 

Data  Link  Layer 

Network  Layer 

Transport  Layer  - 

Session  Layer 

Presentation  Layer 


DESCRIPTION  .  . . 

Physical  connections  necessary  to  transmit  data 
on  a  bit  I/O  level 

Transforms  raw  bits  into  error-free  line  to 
network  layer 

Groups  data  into  packets,  routes  packets  to 
destination,  performs  error  accounting 

Accepts  data  from  session  layer,  forwards  to 
network  layer,  assures  end-to-end  accountability 

User  interface  to  network,  handles  connection 
establishment 

Library  of  common  application  functions  shared 
among  users 


Application  Layer  Unique  messages  handling  specific  to  application 
Figure  3.  ISO  OSI  Seven-Layered  Model 


5 


MCS 

ISO  MODEL 

TACFIRE 

-  - 

Layer  7 

Tactical  Events  Simulation 

Message  Format  Definition 

Application  Layer 

Message  Format  Definition 

Layer  6 

SYS;F0RM  Format  Skeleton 
Transmission 

Abridging  of  Messages 

Presentation  Layer 

Messaqe  Compaction 

Remote  Requests  (filing, 
deletion,  retrieval ) 

Layer  5 

Session  Layer 

Serialization,  Validation 

Layer  4 

Message  of  Interest  Routing 

End-to-End  Accountability 

Transport  Layer 

Remote  Loop  Test 

Routing/Relay 

Layer  3 

Autodial 

Network  Layer 

Subscriber  Table 

EDC/TDC/Double  Blocking 

Layer  2 

EDC/TDC 

ACK/AUTORETRY 

Data  Link  Layer 

ACK/NAK/AUTORETRY 

FSK  4-Wire  600,  1200  Baud 

Conditioned  Diphase 

8K,  16K,  32K  Baud 

Layer  1 

Physical  Layer 

FSK  4-Wire  600,  1200  Baud 

55-Wire  Parallel  Interface 

Figure  4.  MCS  and  TACFIRE  Processes  Mapped  to  ISO  Model 
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Figure  5.  Real-Time  Message  Traffic 


2.0  DETAILS  OF  INVESTIGATION 

2.1  Identification  of  Systems 


a.  This  methodology  investigation  had  three  main  tasks.  The  initial 
task  was  to  examine  Army  (TI  systems  which  have  real-time  control  functions 
that  cannot  be  tested  using  precomposed  test  message  streams.  The  second  task 
was  to  identify  the  specific  processes  and  the  required  inputs  and  outputs  for 
each  system  previously  identified.  The  final  task  was  to  determine  feasible 
additions  to  the  TIS  design  requirements  to  accommodate  an  adequate  real-time 
process  simulation  capability  as  those  requirements  and  their  documentation 
are  developed. 

b.  The  initial  effort  associated  with  this  investigation  was  to  identify 
Army  systems  for  further  study.  The  scope  was  limited  to  those  systems 
depicted  in  the  representation  of  the  Army  Battlefield  Automated  Systems  (BAS) 
concept  in  figure  6.  The  investigation  identified  TACFIRE  and  MCS  for 
detailed  study.  Both  of  these  systems  are  executive  systems  under  the  BAS 
concept  and  communicate  via  character-oriented  digital  message  exchange. 

2.1.1  Bit-Oriented  Versus  Character-Oriented  Messages 

a.  The  TSQ-73  and  HAWK  missile  systems  were  examined  briefly  to  obtain  a 
fuller  understanding  of  the  structure  and  philosophy  of  Army  systems  using 
bit-oriented  messages  for  communications.  This  examination  led  to  the 
conclusion  that  major  functional  differences  exist  between  the  bit-oriented 
and  character-oriented  types  of  message  exchange. 

b.  The  differences  between  the  two  types  of  message  exchange  are  not 
inherent  in  the  definition  of  field  size  in  terms  of  bits  or  characters.  The 
differences  spring  from  the  diverse  purposes  of  the  information  transfered. 

MCS  and  TACFIRE  messages  are  character-oriented.  Processers  being  controlled 
by  MCS  and  TACFIRE  rely  largely  on  operator  intervention  for  real-time 
generation  of  messages.  TSQ-73  and  HAWK  messages  are  bit-oriented.  Message 
generation  is  controlled  by  a  complex  combination  of  outside  events,  operator 
intervention,  and  response  to  incoming  message  information.  Processes  being 
controlled  and  described  by  the  message  exchange  between  TSQ-73  and  HAWK  are 
time  critical,  and  real-time  computer-generated  messages  are  essential  for 
information  exchange  to  be  maintained. 

2.1.2  Use  of  the  ISO  Protocol  Reference  Model 


a.  It  is  apparent  that  support  of  such  widely  diverse  systems  with  a 
single  TIS  requires  a  well -coordinated  design  philosophy.  It  is  necessary, 
therefore,  to  establish  a  common  base  for  comparison  of  tactical  communication 
protocols.  Figure  3  illustrates  the  ISO  reference  model's  layered  concept  of 
a  communications  protocol.  The  layers  identified  in  figure  3  will  be  used 
throughout  this  report  to  describe  tactical  communication  protocols. 


Figure  6 
Army  BAS  Concept 
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b.  Communication  with  each  system  requires  some  rudimentary  communi¬ 
cation  protocol  interface.  In  the  TIS,  this  type  of  protocol  handling  is 
performed  in  the  SSA.  The  SSA  is  the  part  of  the  TIS  real-time  software  that 
performs  highly  specialized  functions  requiring  re-implementation  from  SUT- 
to-SUT. 
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c.  Layers  1,  2,  and  3  of  the  ISO  model  are  necessary  for  any  message  ex¬ 
change  to  occur.  These  layers  are  mandatory  for  minimal  SSA  implementation. 
Layer  4  is  a  bridge  between  the  essential  lower  three  layers  and  the  system- 
tailored  upper  three  layers.  Layer  4  assures  end-to-end  message  transfer  and 
provides  logical  (named)  rather  than  physical  (hard-wired)  addressing  of 
nodes.  It  is  highly  desirable  to  implement  the  layer  4  function  in  an  SSA. 
This  allows  logical  node  addressing  on  the  message-generation  level.  Process¬ 
es  representing  layers  5,  6,  and  7  are  not  essential  to  message  exchange. 
Omission  of  processes  representing  layers  5  to  7  may  cause  error  conditions  or 
illogical  event  sequences.  Those  processes  from  layers  5  to  7  which  must  be 
simulated  to  meet  testing  requirements  will  be  identified.  Simulation  of  the 
sequences  of  events  in  layers  5  to  7  in  a  tactical  protocol  may  be  accom¬ 
plished  by  careful  scripting.  This  report  will  identify  those  items  which  can 
most  effectively  be  supported  by  generation  of  messages  during  real  time. 

2.2  TACFIRE 


2.2.1  TACFIRE  Message  Types 

TACFIRE  uses  four  basic  types  of  messages.  These  are  application, 
control,  test,  and  system  messages.  These  messages  share  the  same  communica¬ 
tion  line  format  and  are  transmitted  using  the  same  rules.  The  types  differ 
primarily  in  content.  They  are  categorized  as  required,  desirable,  and 
scriptable  as  shown  in  figure  2. 

2.2.2  Real-Time  Processes  Required  for  SSA 

Implementation  of  a  TACFIRE  SSA  that  includes  processes  corresponding  to 
the  ISO  model  for  layers  1  to  3  (and  serialization)  would  allow  basic  message 
exchange.  This  implementation  must  include  the  five  functional  areas  listed 
in  table  I. 


TABLE  I.  MINIMUM  TACFIRE  SSA  REQUIREMENTS 
Physical  Interface  (layer  1) 

Generation  and  Decoding  of  EDC/TDC  (layer  2) 

Generation  arid  Response  to  ACK/NAK/No  Response  (layer  2) 
Maintenance  of  a  TACFIRE-like  Subscriber  Table  (layer  3) 
Serialization  and  Validation  (layer  5) 


2.2.2. 1  Layer  1,  Physical  Interface 

a.  TACFIRE  TF-A,  TF-B,  and  TF-C  interfaces  support  different  configur¬ 
ations  of  TACFIRE  equipment.  As  illustrated  in  figures  7,  8,  and  9,  these 
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Figure  7.  TF-A  Interface 


Figure  8.  TF-B  Interface 


different  configurations  have  a  common  transmission  i ink.  This  is 

indicated  on  the  figures  by  the  description  COMM  MEDIA,  WIRE,  FM  RADIO,  AM 
RADIO. 

b.  The  signal  produced  for  transmission  across  the  serial  link,  wire  or 
radio  may  be  either  600+0.6  bps  or  1200+1.2  bps.  The  modulation  is  a  contin¬ 
uous  phase  frequency  shift  keying  (FSK)7  where  a  1200+1.2  Hz  wave  train 
represents  a  logical  1  and  2400+2.4  Hz  represents  a  logical  0.  For  wire 
communications,  the  output  leveT  will  be  0+2  dbm  into  600  ohms. 

c.  The  beginning  of  each  serial  message  consists  of  a  series  of 
alternating  ones  and  zeros  used  to  achieve  bit  synchronization.  These 
keytimes  are  operator-selectable  and  vary  with  different  TACFIRE  equipment. 

d.  The  TF-A  format  may  also  use  a  55-wire  parallel  data  link.  This 
interface  is  described  in  detail  in  appendix  C. 

2. 2. 2. 2  Error  Detection  and  Correction  (EDC)  Process 

TACFIRE's  EDC  consists  of  12/7  Hamming  code  which  is  applied  to  every 
seven-bit  character  in  the  cryptographic  synchronization,  message  body,  and 
message  ending  fields  of  a  TACFIRE  message.  This  code  allows  the  correction 
of  single-bit  errors  and  the  detection  of  double-bit  errors  within  a 
character.  (See  appendix  D  for  the  Hamming  code.)  Messages  may  optionally  be 
transmitted  in  the  double  block  mode,  where  each  16-character  block  is  trans¬ 
mitted  twice.  In  double  block  mode,  the  first  block  is  used  unless  it  con¬ 
tains  uncorrectable  errors,  in  which  case  the  second  block  is  used.  If  the 
second  block  is  unusable,  the  message  is  not  acknowledged,  causing  retrans¬ 
mission  of  the  message  by  the  sender.  EDC  is  part  of  layer  2,  the  data  link 
layer,  as  defined  in  the  ISO  model. 

2. 2. 2. 3.  Time  Dispersal  Coding  Process 

TACFIRE's  time  dispersal  coding  (TDC)  is  a  logical  scheme  to  minimize  the 
occurrence  of  multiple  bit  errors.  TDC  is  a  bit  interleaving  technique  where 
sixteen  12-bit  characters  are  transmitted  as  a  block.  The  first  16  bits 
transmitted  are  the  least  significant  bits  for  each  character.  The  remaining 
bits  are  transmitted  in  16-bit  groups  consisting  of  one  bit  from  each  charac¬ 
ter  until  all  bits  have  been  transmitted.  Figure  10  shows  the  order  in  which 
the  bits  for  a  16-character  block  would  be  transmitted.  TDC  is  part  of  the 
ISO  model's  layer  2,  the  data  link  layer. 

2. 2. 2. 4  Control  Message  Process 


a.  TACFIRE  control  messages  ACK  and  NAK  have  unique  formats  determined 
by  the  configuration  of  the  system.  All  ACK  and  NAK  formats  are  16  characters 
long.  The  first  character  of  a  control  message  contains  the  destination,  the 
sixth  contains  the  source,  and  the  eighth  contains  an  American  Standard  Code 
for  Information  Interchange  (ASCII)  ACK  or  NAK  character.  Figure  11  contains 
the  details  of  the  various  ACK  and  NAK  message  formats.  Figure  12  compares  a 
communication  header  to  a  summary  ACK  format. 

b.  The  TACFIRE  SSA  must  have  the  ability  to  select  an  interface  type 
during  initialization  in  order  for  the  correct  control  messages  to  be 
generated.  The  SSA  should  respond  to  a  NAK  condition  by  attempting  automatic 
resynchronization  where  appropriate.  When  automatic  resynchronization  is  not 
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Figure  11.  ACK/NAK  Formats 


Communications  Line  Header— Received  Message 


Figure  12.  Field  Comparison  Between  Communications  Li 


possible,  the  condition  should  be  logged  and  the  operator  notified.  The  SSA 
should  respond  to  a  nonacknowledgement  (no  response)  by  generating  retry 
transmissions  for  three  tries.  After  the  third  nonacknowledgement,  a  channel 
fault  should  be  logged.  In  the  event  of  channel  fault  or  an  auto-resynchroni¬ 
zation  failure,  it  is  desirable  to  provide  an  operator  interface  to  allow  TIS 
to  use  TACFIRE  manual  resynchronization  techniques.  The  control  message 
process  is  part  of  layer  2,  the  data  link  layer,  as  defined  by  the  ISO  model. 

2. 2. 2. 5  Subscriber  Table  Maintenance  Process 

a.  The  TIS  TACFIRE  SSA  must  maintain  a  TACFIRE-like  subscriber  table  to 
communicate  in  the  TACFIRE  environment.  Data  must  be  stored  by  TIS  for  each 
simulated  or  live  subscriber. 

b.  A  minimal  TIS  subscriber  table  should  consist  of  the  entries  shown 
in  table  II. 


TABLE  II. 

TIS  SUBSCRIBER  TABLE 

PH  SUB 

TIS  CHANNEL  NUMBER 

SEQ 

SERIAL  NUMBER 

TRN 

TRANSMIT  REPEAT  NUMBER 

c.  PH  SUB  is  used  in  TACFIRE  for  physical  subscriber  addressing 
information.  In  TIS,  the  PH  SUB  fields  would  contain  the  communication 
channel  number  for  a  subscriber.  The  SEQ  field  would  contain  the  next  unused 
serial  number  for  send  and  receive.  The  Transmit  Repeat  Number  (TRN)  field 
would  store  the  most  recently  used  TRN  for  each  channel.  The  TIS  software 
would  maintain  current  TRNs  for  each  channel  under  this  scheme.  Subscriber 
table  maintenance  provides  physical  address  of  service,  which  is  part  of  layer 
3  of  the  ISO  model,  the  network  layer. 

d.  Those  layer  1  through  3  functions  which  are  an  integral  part  of  the 
TACFIRE  protocol  have  been  discussed.  All  of  these  functions  should  be 
supported  in  a  TIS  TACFIRE  SSA.  Other  areas  exist  which  have  definable  real¬ 
time  processes  that  are  desirable  but  not  mandatory  in  a  TIS  environment. 

2.2.3  Real-Time  Processes  Optional  for  TACFIRE  SSA 

Some  layer  4  through  7  processes  should  be  supported  in  real  time  for  a 
fully  operational  system  but  are  less  critical.  Omission  of  these  processes 
might  cause  error  and  warning  messages  but  would  not  preclude  message  ex¬ 
change. 

2.2.3. 1  Loop  Test  Process 

a.  The  TACFIRE  system  transmits  and  responds  to  internal  loop  test 
messages  generated  automatically  as  a  result  of  internal  parameters.  These 
messages  are  normally  exchanged  between  the  TACFIRE  Fire  Direction  Center 
(FDC)  and  its  remote  subscribers.  The  loop  test  messages  may  •  i  once  or  at 
regular  intervals.  Figure  13  shows  a  sample  loop  test  message.  Full 


implementation  of  the  remote  loop  test  process  would  require  the  functions 
described  in  table  III. 

1)  If  VFMED  initiates  remote  test  with  the  following  loop  test  message: 


ZOO 140 

MD;XMT2;TEST:  0123456789 

TACFIRE  responds  with  acknowledgement  (ACK) 

00015ZSx 

2)  If  VFMED  initiates  remote  test  with  the  following  loop  test  message: 
Z00240; 

MD;RCV2;TEST:  9876543210 
TACFIRE  generates  and  transmits  a  response: 

00014Z;R: 7;SB: F/S/E/  /  ;C:UN  ;SG:1  ,1  ;DT:02,09/23/22;ID202;  A: A; 
MD;RCV2:TEST :  9876543210 

Z  30Ax 


Figure  13.  Loop  Test  Examples 


The  loop  test  process  is  used  to  verify  that  a  valid  end-to-end  path  exists 
between  two  given  nodes  and  is  logically  a  part  of  the  ISO  model  layer  4.  It 
is  desirable  but  not  necessary  for  message  exchange  to  include  this  function  in 
a  TACFIRE  SSA. 


TABLE  III.  FUNCTIONS  REQUIRED  FOR  LOOP  TEST  MESSAGE  PROCESSES 
Echo  of  Input  Test  Messages 
Definition  of  Interval  Timer 
Generation  of  Test  Messages 
Logging  of  Test  Messages 


b.  Appendix  E  describes  the  SYS ;MI SC  and  SYS;MDS,  miscellaneous  and 
message  and  diagnostic  test  messages,  message  formats  which  control  the  loop 
test  message  process  in  a  TACFIRE  system. 

2. 2. 3. 1.1  Echo  of  Input  Test  Messages 

Some  test  messages  received  by  the  TIS  should  be  echoed  back  to  the 
originator  while  others  should  simply  be  acknowledged.  Figure  13  illustrates 
examples  of  each  case.  The  determining  factor  in  items  1,  3,  and  4  of  figure 
13  is  the  field  before  the  TEST  field,  which  contains  either  RCVn  or  XMTn.  If 


the  TIS  receives  a  message  with  that  field  containing  RCVn,  the  source  and 
destination  should  be  switched  and  the  message  should  be  echoed  on  the  channel 
it  came  from.  A  received  message  with  XMTn  in  that  field  should  be  treated  as 
a  routine  received  message  and  should  simply  be  logged  and  acknowledged. 

2.2.3. 1.2  Definition  of  Interval  Time 

The  TACFIRE  SSA  must  maintain  an  interval  timer  to  emulate  the  TACFIRE 
test  message  process.  In  TIS  this  timer  could  be  initialized  from  the  ini¬ 
tialization  file.  Alternatively,  the  SSA  could  extract  the  interval  from  the 
Remote  Loop  Test  Interval  (RLPI)  field  on  an  incoming  SYS ;MI SC  message.  This 
message  is  described  in  appendix  E.  TACFIRE' s  legal  range  for  this  parameter 
is  0  to  59  minutes,  with  a  default  of  30  minutes. 


2.2.3. 1.3  Periodic  Generation  of  Test  Messages 

The  SYS;MDS  message,  described  in  appendix  E,  is  used  in  TACFIRE  to 
initiate  various  self-test  features.  If  the  RL00P  field  is  used,  the  remote 
loop  test  will  run,  causing  the  generation  of  a  test  message  or  messages.  An 
entry  of  S  will  specify  that  a  single  test  message  be  generated  at  the  next 
expiration  of  the  interval  timer  (discussed  in  paragraph  2. 2. 3. 1.2).  An  entry 
of  M  in  the  RL00P  field  will  cause  generation  of  multiple  test  messages,  one 
for  each  expiration  of  the  interval  timer.  The  SSA  could  extract  this 
information  from  incoming  messages,  or  it  could  simply  read  an  RL00P  parameter 
from  an  initialization  file.  The  SSA  could  then  generate  test  messages  similar 
to  those  shown  in  figure  13  at  the  time-specified  intervals. 

2. 2. 3. 1.4  Logging  of  Test  Messages 

Test  messages  received  by  TIS  must  be  logged  in  the  same  manner  as  all 
incoming  messages.  The  log  file  should  also  record  any  TIS-initiated  test 
messages  and  all  modifications  to  the  RLPI  and  RL00P  parameters  of  the  SYS;MDS 
message  of  appendix  E. 

2. 2. 3. 2  Serialization  and  Validation  Process 

The  TIS  TACFIRE  SSA  must  have  the  ability  to  validate  messages.  One 
method  of  accomplishing  this  is  serialization  through  use  of  the  SEQ  parameter 
in  the  TIS  subscriber  table.  SEQ  would  be  incremented  for  each  message 
transmitted  on  a  channel.  The  SEQ  value  from  the  table  would  be  inserted  into 
the  communications  line  for  each  message  transmitted.  TIS  must  insert  an 
updated  transmit  repeat  number  in  the  communications  line  of  retries  due  to 
nonacknowledgement  from  the  SUT.  Received  messages  would  be  acknowledged  and 
logged  without  regard  to  serialization.  The  TACFIRE  serialization  technique 
should  be  employed  by  TIS  as  opposed  to  an  authentication  matrix.  Although 
serialization  and  validation  logically  fit  into  layer  5,  the  session  layer  of 
the  ISO  model,  TACFIRE  has  forced  this  function  to  become  part  of  the  criteria 
for  message  exchange  at  level  3.  This  information  could  be  included  in 
prescripted  messages,  assuming  an  error-free  transmission  line. 

2. 2. 3. 3  Application  Messages 

Application  messages  correspond  to  layer  7  in  the  ISO  model.  Most 
application  messages  in  TACFIRE  can  be  supported  by  prescripting  during  the 
pre-test  phase.  Real-time  processing  at  the  application  level  may  be 


considered  as  event  processing.  A  tactical  event  may  be  described  in  terms  of 
specific  message  sequences.  Those  messages  may  be  arbitrarily  generated  in  a 
predetermined  sequence  to  represent  the  event.  Messages  which  are  difficult  to 
generate  during  pre-test  or  which  are  time  critical  and  unpredictable  during 
real-time  must  be  supported  by  real-time  process  simulation  if  they  are  to  be 
tested. 


2. 2. 3. 3.1  FM;RFAF  (Fire  Mission;  Request  For  Additional  Fire)  Event 

Figure  14  shows  a  message  sequence  which  could  represent  a  tactical  event. 
By  defining  the  event  parameters  to  include  only  the  link  between  battalion 
(BN)  and  division  artillery  (DIVARTY),  the  sequence  FM;RFAF,  FM;MFR,  FM;E0M 
(Fire  Mission;  Mission  Fired  Report,  Fire  Mission;  End  of  Message)  could 
represent  a  BN  FDC.  A  stream  of  scripted  messages  from  the  TIS  (BN)  could  be 
transmitted  to  the  division  TACFIRE  computer.  In  response  to  an  FM;RFAF  from 
division,  the  simulated  BN  FDC  would  generate  FM;MFR  and  FM;E0M  and  insert  them 
into  the  message  stream.  This  message  stream  generated  in  real  time  would 
include  data  representing  the  action  of  the  forward  observer  (using  a  TFDMD) 
and  fire  unit  (using  a  VFMED)  controlled  by  the  TACFIRE  BN  FDC.  Because 
scripted  messages  could  be  created  easily  to  give  the  same  results  as  the 
real-time  event  processing,  this  application  layer  process  could  be  supported 
without  the  need  for  real-time  process  simulation. 

2. 2. 3. 3. 2  SYS; FORM  (SYSTEM; FORMAT)  Event 

Defining  the  parameters  of  the  event  differently  would  lead  to  different 
real-time  processing  requirements.  If  TIS  were  representing  the  BN  FDC  and  its 
link  to  the  fire  support  officer  (FSO),  figure  15  might  realistically  describe 
the  event.  The  event  represented  by  figure  15  would  be  the  update  of  zone  of 
responsibility  parameters  at  FDC  by  the  FSO.  The  messages  involved  are 
SYS;F0RM  and  SPRT;ZNE.  These  message  formats  are  described  in  appendix  E.  To 
support  this  configuration,  TIS  would  need  the  capability  of  responding  to  a 
SYS; FORM  request  for  format  by  extracting  a  blank  format  from  the  message 
format  library  (MFL)  and  inserting  it  into  the  message  stream.  Response  to 
SYS;F0RM  would  be  difficult  to  support  with  scripted  messages.  To  support 
SYS; FORM  requests  by  prescripting  the  response,  the  exact  time  of  the  request 
must  be  known  in  order  to  avoid  a  situation  wherein  a  response  is  sent  before 
the  corresponding  request.  The  possibility  exists  in  a  scripted  environment 
for  other  message  loading  factors  to  affect  the  rate  at  which  the  scenario  is 
executed,  thus  causing  messages  to  be  transmitted  out  of  sequence  or  at  a  time 
other  than  planned.  For  this  reason,  real-time  generation  of  the  blank  message 
formats  is  an  attractive  solution  to  support  the  SYS; FORM  process.  The 
SYS; FORM  process  fits  the  ISO  model  definition  for  layer  6,  the  presentation 
layer. 


2. 2. 3. 3. 3  Message  of  Interest  Processing 

a.  One  TACFIRE  process  which  would  create  a  high  volume  of  message 
traffic  is  message  of  interest  (MOI)  processing.  In  a  TACFIRE  configuration,  a 
subscriber  may  designate  specific  message  types  to  be  handled  by  the  MOI 
process.  When  the  computer  (for  example,  BN  FDC)  processes  a  message,  the  MOI 
process  causes  a  copy  of  the  message  to  be  forwarded  to  those  subscribers  whose 
MOI  criteria  include  the  message.  Messages  may  be  designated  as  MOI  for  input, 
output,  or  both.  Action  codes  A,  B,  or  C  are  associated  with  messages  of 
interest.  Table  IV  describes  the  effect  of  these  action  codes. 
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Figure  15.  Tactical  "Event":  TACFIRE  SYS;FORM 
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TABLE  IV.  ACTION  CODES 

r 

ACTION  CODE 

RESULT 

A 

Forward  all  messages 

B 

Send  if  from  my  observer 

or 

Send  if  in  my  zone  of  responsibility 

C 

Send  if  only  from  my  observer 

b.  ITIS  support  for  MOI  processing  which  relied  entirely  upon  prescripted 
messages  would  be  extremely  difficult.  The  scenario  designer  would  be  required 
to  examine  all  messages  manually  to  check  for  the  MOI  criteria  and  to  create 
duplicate  copies  of  those  messages  which  met  them.  To  support  MOI  processing 
in  TIS  during  real  time,  the  SYS;FS0  message  would  be  examined  to  extract  MOI 
criteria.  Alternatively,  the  MOI  criteria  could  be  established  at  ini¬ 
tialization.  An  MOI  process  would  require  an  internal  file  containing  infor¬ 
mation  on  zones  of  responsibility  and  observer  assignments.  The  output  of  the 
process  would  be  real-time  insertion  of  copies  of  messages  from  the  scenario 
which  met  MOI  criteria  in  the  appropriate  message  streams.  All  real-time¬ 
generated  messages  of  interest  would  be  logged  as  they  are  transmitted.  This 
layer  4  (transport  layer)  process  would  provide  a  means  of  increasing  network 
traffic,  which  would  be  useful  in  support  of  saturation  testing. 

2.3  MANEUVER  CONTROL  SYSTEM 

The  MCS  real-time  processes  were  compared  to  the  ISO  model  in  figure  4. 

The  low-level  protocol  routines  correspond  to  ISO  layers  1,  2,  and  3. 

End-to-end  accountability  is  part  of  ISO  layer  4.  Remote  filing  could  be 
compared  to  the  ISO  layer  5.  Abridging  and  message  format  definition  fit  into 
layers  6  and  7.  Like  TACFIRE's,  MCS  processes  can  be  categorized  as  required, 
desirable,  and  scriptable  (figure  1). 

2.3.1  Protocol  Interface  Routines  Required  for  an  MCS  SSA 

For  MCS,  as  with  TACFIRE,  the  layer  1,  2,  and  3  processes  are  required  to 
support  basic  message  exchange.  In  MCS,  the  required  processing  for  the  SSA 
includes: 


Physical  Interface 
Error  Detection  and  Correction 
Time  Dispersal  Coding 
Autodial 

Message  Forwarding 
2.3. 1.1  Physical  Interface 

MCS  may  exchange  data  over  the  physical  interface  described  for  TACFIRE 
(paragraph  2. 2. 2.1).  Additionally,  MCS  supports  interconnection  through  a 
conditioned  diphase  modem  at  bit  rates  of  8K,  16K,  and  32K.  The  conditioned 
di phase  modem  supports  a  selectable  key  time  from  1  to  99  seconds. 
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2.3. 1.2  Error  Detection  and  Correction  Process 


MCS's  EDC  consists  of  a  12/7  Hamming  code  which  is  applied  to  every 
seven-bit  character  in  an  MCS  message.  This  code  allows  the  correction  of 
single  bit  errors  and  the  detection  of  double  bit  errors,  within  a  character. 
See  appendix  D  for  the  Hamming  code.  Messages  may  optionally  be  transmitted  in 
the  double  block  mode,  where  each  16-character  block  is  transmitted  twice.  In 
double  block  mode,  the  first  block  is  used  unless  it  contains  uncorrectable 
errors;  in  which  case  the  second  block  is  used.  Some  service  messages  will  be 
triple  blocked  to  assure  their  receipt.  If  the  third  block  is  unusable,  the 
message  is  not  acknowledged,  causing  retransmission  of  the  message. 

2. 3. 1.3  Time  Dispersal  Coding  Process 

MCS's  TDC  is  a  logical  scheme  to  minimize  the  occurrence  of  multiple  bit 
errors.  TDC  is  a  bit  interleaving  technique  wherein  twelve  16-bit  characters 
are  transmitted  as  a  block.  The  first  16-bit  characters  transmitted  are  the 
least  significant  bits  for  each  character.  The  remaining  bits  are  transmitted 
in  16-bit  groups  consisting  of  one  bit  from  each  character  until  all  bits  have 
been  transmitted.  Figure  10  shows  the  order  in  which  the  bits  for  a  16-char¬ 
acter  block  would  be  transmitted. 

2.3. 1.4  Autodial 

The  MCS  has  the  capability  to  use  automated  telephone  dialing  equipment. 
The  originating  node  has  the  ability  to  seize  the  line,  dial  a  distant  node, 
sense  line  status,  and  transmit  messages.  The  receiving  node  senses  an 
incoming  call,  seizes  the  line,  and  receives  messages.  Both  the  Tactical 
Computer  Terminal  (TCT)  and  the  Tactical  Computer  System  (TCS)  include  a  0-29 
digit  telephone  number  in  the  node  descriptions  defined  at  initialization.  TIS 
support  for  the  autodial  function  would  require  storage  of  an  operator-entered 
telephone  number  for  each  node  and  physical  interface  such  as  the  3614 
switchboard  or  the  AN/TTC-38  telephone  central  office. 

2.3. 1.5  Message  Forwarding 

The  MCS  is  capable  of  forwarding  incoming  messages.  At  initialization, 
the  operator  associates  each  logical  node  address  with  a  physical  channel 
number.  If  a  TCT  or  TCS  receives  a  message  addressed  to  another  node,  the 
address  is  checked  against  the  list  of  valid  destinations.  If  a  match  is 
found,  the  message  is  forwarded  to  the  addressee.  TIS  support  for  message 
forwarding  could  be  provided  by  the  addition  of  a  table  linking  logical  node 
addresses  to  channel  numbers.  The  SSA  would  check  each  incoming  message  to 
determine  whether  the  logical  addressee  was  correct  for  the  receiving  channel. 
If  the  two  did  not  match,  the  address  would  be  checked  against  the  SSA's 
destination  table.  The  message  would  be  forwarded  if  a  match  were  found; 
otherwise,  an  error  message  would  be  generated. 

2.3.2  Real-Time  Processes  Optional  for  MCS  SSA 

The  layer  4  through  7  processes  described  in  the  next  few  paragraphs  are 
optional  in  the  implementation  of  the  MCS  SSA.  Without  these  processes  in  the 
TIS,  the  SUT  may  experience  some  error  conditions,  but  message  exchange  would 
be  possible  between  the  TIS  and  MCS. 
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2.3.2. 1  End-to-End  Accountability  Processing 

a.  The  MCS  has  the  ability  to  request  end-to-end  accountability  for  any 
message.  This  feature  provides  the  originating  station  with  a  positive 
response  for  use  in  determining  whether  a  relayed  message  successfully  reached 
the  addressee.  When  the  addressed  node  successfully  receives  a  message 
requiring  end-to-end  accountability,  it  generates  an  end-to-end  acknowledgement 
(E/E  ACK)  addressed  to  the  originator  of  the  message.  In  the  event  of 
unsuccessful  relay,  an  end-to-end  negative  acknowledgment  (E/E  NAK)  will  be 
generated  by  the  relay  node  at  which  local  acknowledgment  failed.  This  E/E  NAK 
is  sent  back  to  the  message  originator  and  may  then  be  used  to  determine  where 
the  fault  occurred.  This  process  works  as  shown  in  figure  16. 

b.  The  message  depicted  in  this  figure  is  originated  at  node  1  and  is 
addressed  to  node  5.  Each  node  first  attempts  to  transmit  the  message  along 
the  line  on  its  primary  path.  If  the  message  is  not  acknowledged,  the  node 
attempts  its  secondary  path.  If  all  secondary  paths  also  fail,  the  last  node 
which  successfully  received  the  message  originates  an  E/E  NAK  and  sends  it  back 
to  the  node  that  originated  the  process,  in  this  case  node  1.  If  the  message 
does  reach  node  5,  node  5  is  responsible  for  originating  an  E/E  ACK  to  be 
transmitted  back  to  node  1. 

c.  For  the  MCS  SSA  to  have  the  capability  to  emulate  any  of  the  nodes  in 
this  configuration,  it  must  be  able  to  handle  end-to-end  accountability  for 
this  processing.  The  TIS  must  decode  the  incoming  message  to  determine  whether 
end-to-end  accountability  had  been  requested.  If  it  was  requested,  the  SSA 
would  use  information  provided  by  the  scripted  scenario  to  determine  the 
appropriate  response.  Responses  would  include  origination  of  service  messages 
such  as  an  E/E  ACK,  origination  of  an  E/E  NAK,  or  no  response. 

2. 3. 2. 2  Remote  Filing 

a.  An  operator  of  any  MCS  node  has  the  option  of  filing  a  message  at  any 
valid  destination  node.  The  destination  node  has  the  option  of  filing  this 
message  or  sending  a  "request  denied"  message  back  to  the  originating  node. 

When  a  message  has  been  filed  remotely  at  a  node,  the  filing  node  has  the 
responsibility  to  support  requests  for  retrieval  or  deletion  of  the  message. 

The  filing  node  can  either  reject  these  requests  or  process  them.  If  the 
autoprocessing  feature  is  selected,  remote  retrieval  will  take  place  with  no 
operator  intervention.  Associated  with  this  filing  capability  is  a  directory 
of  messages  filed  which  must  be  provided  to  the  originating  station  upon 
request.  The  MCS  Remote  Request  (RR)  message  supports  the  functions  listed  in 
table  V. 


b.  To  support  testing  of  the  MCS  RR  function,  the  SSA  must  have  the 
capability  of  generating  responses  to  these  MCS  messages.  Because  the  messages 
that  would  be  filed  and  retrieved  would  originate  at  the  SUT,  very  careful  and 
meticulous  scripting  of  a  scenario  would  be  required  to  accomplish  testing  of 
remote  requests  without  real-time  processing. 

c.  An  SSA  real-time  capability  to  support  RR  could  be  implemented  in  two 
ways.  The  first  option  would  simulate  the  actual  filing  and  retrieval  of 
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n  1  =  node  #n 


Figure  16.  Sample  Network  Topology  Illustrating 
End-to-End  Paths 


TABLE  V.  MCS  MESSAGES  SUPPORTED  BY  RR  MESSAGE  FORMAT 
Remote  Filing 
Remote  Retrieval 
Remote  Deletion 
Request  Denied 


messages.  This  option  would  require  support  of  at  least  a  minimal  DBMS 
capability  to  store  incoming  messages.  Subsequent  retrieval  requests  would 
result  in  the  SSA  retrieving  the  stored  data  and  generating  the  proper  blank 
message  format  to  transmit  data.  The  message  would  then  be  inserted  into  the 
message  stream  being  transmitted  to  the  SUT. 

d.  The  second  option  for  support  of  remote  filing  is  much  simpler  to 
implement  but  would  not  provide  as  complete  a  set  of  options  for  stimulation  of 
the  SUT.  This  method  would  simply  cause  the  TIS  to  transmit  a  request  denied 
message  or  a  canned  message  in  response  to  all  remote  filing,  remote  retrieval, 
and  remote  deletion  requests.  This  response  would  cause  the  sending  MCS 
operator  to  take  other  action  as  directed  by  the  scenario. 

2.4  Test  Item  Stimulator 

The  transportable  (van-mounted)  TIS  supports  three  operational  functions 
used  to  perform  DT  of  C3I  systems: 

.  Pre-test  scenario  prepartion. 

.  Real-time  SUT  stimulation. 

.  Post-test  data  reduction  and  analysis. 

2.4.1  Pre-Test 

The  test  scenarios  that  drive  the  real-time  SUT  stimulation  are  generated 
interactively  through  the  pre-test  function.  These  scenarios  are  composed  of: 

a.  Command  messages.  These  messages  direct  the  real-time  TIS  activity, 
including: 

.  Loading  an  SSA. 

.  Starting  the  test. 

.  Checkpointing  the  test. 

.  Restarting  from  a  checkpoint. 

.  Adding  messages  during  the  test. 


.  Deleting  messages  during  the  test. 

.  Modifying  parameters  controlling  the  execution  of  the  real-time  code 
(SSA) . 

b.  Pre-scripted  messages.  These  are  the  tactical  messages  that  are  sent 
to  the  SUT  without  major  modification.  These  include  both  character-oriented 
and  bit-oriented  messages. 

c.  Real-time  messages.  These  messages  contain  information  used  to 
control  the  real-time  generation  of  message  streams  for  transmission  to  the 
SUT. 

d.  Response  Messages.  These  messages  are  stored  in  a  response  table. 
Messages  from  the  SUT  are  compared  with  the  table  and  if  a  match  is  found,  the 
corresponding  response  is  transmitted  back  to  the  SUT. 

e.  Test  notes.  These  messages  are  logged  along  with  the  real-time 
message  exchange  to  provide  documentation  for  later  use  during  post-test 
processing. 

2.4.2  Real-Time 

a.  The  real-time  function  provides  the  interface  for  stimulating  and 
monitoring  the  SUT.  The  real-time  function  processes  both  scenario  and 
operator-entered  messages,  producing  a  message  stream  to  stimulate  the  SUT. 

The  resulting  message  exchange  is  logged  for  later  processing.  The  protocol 
handlers,  formatters,  and  interface  elements  dealing  with  a  specific  protocol 
are  collectively  referred  to  as  a  SSA.  Figure  17  depicts  the  data  flow  between 
the  functional  components  of  an  SSA. 

b.  Scenario  based  and  operator-entered  messages  driving  the  real-time 
processing  are  scheduled  through  the  event  reader.  Command  messages  are  routed 
to  the  SSA  control  process,  where  they  modify  the  test  execution.  Pre-scripted 
messages  are  sent  directly  to  the  transmit  process,  which  transmits  data  to  the 
SUT  and  logs  the  transmission.  Real-time  messages  and  response  messages  are 
routed  to  the  real-time  message  generation  and  response  handling  processes, 
which  in  turn,  send  transmittable  messages  to  the  transmit  process.  The 
receive  process  logs  the  SUT  messages  received  and  sends  the  received  data  to 
the  response  handling  task,  possibly  triggering  a  response.  Test  notes  are 
displayed  to  the  operator  and  routed  to  the  logging  process. 

2.4.3  Post-Test 

Post-test  processing  of  the  log  files  generated  during  testing  produces 
statistical  reports  on  message  content  and  end-to-end  system  throughput. 
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METHODOLOGY  INVESTIGATION  PROPOSAL 


1.  TITLE.  Real-Time  Message  Process  Simulation  Capability 

2.  CATEGORY. 

a.  Thrust  Areas. 

TT7 . TTSTT 

(2)  DCJI 

(3)  SMI 

b.  Sub-Areas. 

HI  Software 

(2)  Interoperability 

3.  INSTALLATION.  US  Army  Electronic  Proving  Ground,  Fort  Huachuca,  Arizona 
85613 

4.  PRINCIPAL  INVESTIGATOR.  Leslie  F.  Claudio,  Software  and  Automation 
BrancF,,  '5TErP^^r,',1'RTrrnVDN  879-1879. 

5.  STATEMENT  OF  THE  PROBLEM.  In  testing  message-driven  systems  which  have 
control  functions,  a  method  is  required  for  simulating,  in  real-time,  the 
responses  of  the  controlled  resources  represented  by  the  message  stream  from  a 
Test  Item  Stimulator  (TIS) .  Current  methods  of  testing  using  the  Interim  TIS 
(ITIS)  or  the  TIS  require  that  all  simulation  messages  be  composed  off-line 
prior  to  the  real-time  test.  This  constraint  makes  test  of  real-time  control 
functions  in  a  System  Under  Test  (SUT)  difficult  if  not  impossible. 

6.  BACKGROUND. 

a.  History.  The  Army  is  developing  a  large  number  of  automated  tactical 
command,  control ,  communications,  and  intelligence  ( C*3 1 )  systems.  These 
systems  and  their  many  interfaces  with  each  other  rely  on  digital  message 
exchange  for  input,  output,  and  intra-system  data  exchanges.  Their  performance 
is  frequently  manifested  as  data  in  an  output  message  or  display  and  their 
inputs  as  digital  messages  from  an  operator  device,  a  sensor,  or  an  inter¬ 
operating  system.  To  stimulate  and  acquire  the  responses  from  such  systems, 
devices  called  test  item  stimulators  are  used  to  apply  test  message  streams 
which  have  been  specifically  designed  to  evoke  the  function  of  which  the  SUT  is 
supposed  to  be  capable.  An  interim  or  prototype  TIS  capability  exists  and  is 
being  used  to  support  DT.  TIS'  compatibility  with  other  USAEPG  system  test 
instrumentation  are  included  in  the  MAINSITE  equipment  acquisition. 

b.  Progress.  This  is  a  new  project  for  FY  83. 

7.  GOAL.  To  develop  methods  of  generating,  in  real-time,  information  that  can 
be  inserted  in  test  message  streams  that  would  have  been  performed  by  a  system 
controlled  by  outputs  from  the  SUT. 

8.  DESCRIPTION  OF  INVESTIGATION. 

a.  This  investigation  will  develop  specifications  for  modification  to 
the  basic  ITIS  and  TIS  system  being  acquired  as  part  of  the  MAINSITE  acquisi¬ 
tion. 
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b.  The  US  Army  Electronic  Proving  Ground  will  conduct  the  investigation 
as  follows: 

3 

(1)  Identify  those  Army  C  I  systems  which  will  have  real-time  control 
functions  which  cannot  be  tested  using  pre-composed  test  message  streams  and 
identify  the  processes  that  would  have  to  be  simulated  and  the  information  that 
would  be  required  by  output  from  those  processes. 

(2)  Based  upon  the  design  of  the  ITIS  and  MAINSITE  TIS  system,  identify 
feasible  changes  that  should  be  made  to  the  ITIS/TIS  requirements  and  design 
documentation  to  accommodate  an  adequate  real-time  message  process  simulation 
capability. 


c.  Investigation  Schedule. 


MILESTONE/PHASE 


SCHEDULE 


FY  83  (Qtrs) 
12  3  4 


FY  84  (Qtrs) 
12  3  4 


Identification  of  control  functions  X  X 
in  Army  CJI  systems 

Identification  of  essential  control  X  X 

processes 

Identification  of  control  process  X 

simulation  information  requirements 
FY  83  report 

Engineering  change  proposal (s)  to  X 

ITIS/TIS  requirements  documents 
Engineering  change  proposal (s)  to 
ITIS/TIS  design  documents 
Final  report 


X 

X 

X 


X 


X 

X  X 
X  X 


X 

X 


d.  This  investigation  will  result  in  the  definition  of  procedures  for 
simulating  the  responses  of  systems  being  represented  by  ITIS/TIS  message 
stream.  The  definition  will  be  in  a  form  so  that  it  may  be  used  directly  by 
the  ITIS/TIS  system  maintainer  to  purchase  the  services  required  to  make  the 
changes. 


e.  Environmental  Impact  Statement.  The  execution  of  this  task  will  not 
have  an  adverse  impact  on  the  quality  of  the  environment. 

f.  Health  Hazard  Statement.  No  health  hazards  are  anticipated. 

9.  JUSTIFICATION. 

a.  Mission  and  Impact  Statements. 

(1)  Association  with  mission.  USAEPG's  primary  mission  is  to 
conduct  DT  of  CJI  equipment  and  systems.  Most  of  these  systems  employ  digital 
messages  to  exchange  information.  This  task  is  required  to  enable  the  test  of 
those  CJI  systems  which  have  real-time  control  functions. 

(2)  Present  Capability,  Limitations,  Improvement,  and  Impact  on  Test 
Programs  if  notTerformed  in  the  Proposed  Fiscal  Year.  The  present  capability 
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requires  that  all  test  messages  be  composed  and  validated  prior  to  the  start  of 
a  real-time  test.  Processes  that  a  SUT  might  be  controlling  may  currently  only 
be  reflected  in  the  message  stream  if  they  are  simple,  relatively  slow,  and  if 
the  behavior  of  the  SUT  is  predictable  enough  that  synchronization  of  the  input 
stream  and  outputs  is  not  lost  during  the  test.  A  method  is  required  to  permit 
the  stimulus  messages  to  reflect  information  changes  that  a  SUT  would  expect  in 
response  to  its  outputs.  If  this  investigation  is  not  completed,  controlled, 
repeatable,  and  statistically  significant,  tests  of  the  major  Army  C^I  systems 
that  have  control  functions  will  not  be  possible. 

b.  Dollar  Savings.  The  savings  over  the  alternative  of  not  performing 
those  tests  which-cannot  be  accomplished  with  the  present  method  cannot  be 
computed.  Most  CJI  systems  will  fall  in  this  category  by  1983. 

c.  Workload.  There  are  five  executive  systems  in  the  Army  Command 
Control  System.  Each  has  or  will  have  interfaces  to  many  subordinate  or 
inter-operating  systems.  The  interface  tests  alone  to  be  accomplished  in  the 
1985  to  1995  timeframe  will  number  in  the  hundreds.  Systems  representative  of 
those  to  be  tested  include: 


System 


TECOM 

Priorit 
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Recommended  TRMS  Priorit 


Association  with  Requirements  Documents 


(1)  MAINSITE  TIS  requirements  documents  will  be  the  baseline  to 
which  the  products  of  this  task  will  be  referenced. 

(2)  The  methodology  resulting  from  this  task  will  not  be  tailored 
exclusively  to  the  requirements  of  any  one  specific  SUT,  but  will  be  designed 
to  be  generally  applicable  to  Army  CJI  systems. 

10.  RESOURCES. 


Financial 


(1)  Funding  Breakdown. 

Dollars  (Thousands) 

FY  84 

In-House  Out-of-House 


Personnel  Compensation 

15.0 

Travel 

2.0 

Contractual  Support 

Material  &  Supplies 

0.5 

162.5 

Subtotals 

17.5 

162.5 

FY  Totals 

180.0 

(2)  Explanation  of  Cost  Categories. 

(a)  Personnel  Compensation.  Cover  in-house  labor  costs  for  the 
principal  investigator  and  other  in-house  project  support  personnel. 

(b)  Travel .  Travel  is  required  to  conduct  the  survey  of 
current  technology  and  to  coordinate  the  tasks  with  other  Government  agencies. 

(c)  Contractual  Support.  Approximately  90  percent  of  the  work 
will  be  accomplished  by  a  contractor  under  an  existing  service  contract. 

(d)  Materials  and  Supplies.  Incidental  supplies  will  be 
required  to  support  the  investigation. 

b.  Anticipated  Delays.  No  delays  are  anticipated  at  this  time. 

c.  Obligation  Plan.  (FY  84) 


Obligation  Rate 

£2 _ 

12  3  4 

TOTAL 

(Thousands) 

“  iso  ro  ttj  nr 

180 

d.  In-House  Personnel . 

(1)  Requirements. 

_  FY  84 

Manhours 


Type  Number  Required  Available 

Electronic  Engr  GS-0855  1  600  680 

(2)  Resolution  of  Non-Available  Personnel.  Not  applicable. 
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11.  INVESTIGATION  SCHEDULE. 


FY  84 

0  N  D  J  F  FHTR  J  J  A  S 


W* 


0 


FY  83 

N  D  J  ro  M  J  J  A  S 


In-House 


-  R 


Contract  - - -  -  -  -  —  — - —  —  — 

Symbols 

-  -  -  Active  investigation  (all  categories) 

.  .  .  Contract  monitoring  (in-house  only) 

R  Final  report  due  at  HQ,  TECOM 

12.  ASSOCIATION  WITH  TOP  PROGRAM.  It  is  not  anticipated  that  this  inves- 
tigation  will  result  in  a  new  Test  Operations  Procedure. 

FOR  THE  COMMANDER: 


MELVIN  FOWLER 
LTC,  SigC 

Director  of  Material  Test 


PAGE) 


APPENDIX  B 

DEFINITIONS  AND  ACRONYMS 


ACC  =  Artillery  Control  Console. 

ACK  =  Acknowledgement. 

ASAS  =  All  Source  Analysis  System. 

ATDL-1  =  Automated  Tactical  Data  Link.  Message  format  used  by  TSQ-73  and 
I HAWK. 

BAS  =  Battlefield  Automated  System.  A  term  sometimes  used  to  describe  tactical 
C3I  systems. 

Baud  =  Data  transfer  rate,  bits  per  second  for  binary  singals.  (After  J.M.E. 
Baud. ) . 

BRTS  =  Basic  Real-Time  System 
2 

C  =  Command  and  Control. 

3 

C  =  Command,  Control,  and  Communications. 

3 

C  I  =  Command,  Control,  Communications,  and  Intelligence. 

CCU  =  Communications  Control  Unit. 

CDP  =  Conditioned  diphase.  A  conditioned  diphase  modem  uses  phase  shifts  to 
distinguish  between  a  one  and  a  zero  in  digital  data  transmission. 

CIM  =  Communications-Interface  Module.  The  CIM  is  a  functional  subsystem  of  a 
TCS. 

COM  System  =  Character-oriented  message  system. 

Control  message  =  TACFIRE;  generic  for  ACK  or  NAK  type  messages. 

CSIN  =  COMSEC  Interface. 

CTB  =  Communications  Terminal  Box. 

DT  =  Development  Test 
DIVARTY  =  Division  Artillery. 

DDT  =  Digital  Data  Terminal. 

DoD  =  Department  of  Defense. 

EDC  =  Error  detection  and  correction. 

E/E  =  End-to-end,  having  to  do  with  communication  between  sending  and 
destination  nodes  in  a  network  environment,  not  limited  to  an 
intermediate  relay  in  the  total  path. 

EDB  =  End  of  Block 

FDC  =  Fire  Direction  Center.  TACFIRE  term. 

FO  =  Forward  Observer. 

FSE  =  Fire  Support  Element. 

FSK  =  Frequency-shift  keying.  An  FSK  modem  uses  distinct  frequencies  to 

distinguish  between  a  one  and  a  zero  during  digital  data  transmission. 

FSO  =  Fire  Support  Officer.  TACFIRE  term. 


FU  =  Fire  Unit. 

HIU  =  Host  Interface  Unit 
IOU  =  Input/Output  Unit. 

ISO  =  International  Standards  Organization. 

ITIS  =  Interim  Test  Item  Stimulator.  Digital  message  test  driver  initially 
used  in  testing  MCS. 

ITR  =  Input-to-Register 

JTIDS  =  Joint  Tactical  Information  Distribution  System 
KG  =  Keying  Generator. 

MCS  =  Maneuver  Control  System. 

MED  =  TACFIRE  message  entry  device. 

MFL  =  Message  Format  Library.  Part  of  the  data  base  of  a  TIS  which  defines  the 
message  formats  used  to  communicate/with  a  SUT. 

MO I  =  Message  of  Interest.  Designation  which  may  be  given  to  TACFIRE  messages 
to  indicate  special  processing  and  routing  is  desired. 

NAK  =  Negative  acknowledgement. 

PJH  =  Position  Location  Reporting  System/ JTIDS  Hybrid 
RLPI  =  Remote  Loop  Test  Interval 

Service  message  =  MCS;  generic  for  ACK,  E/E  ACK,  or  E/E  NAK  type  messages. 

SSA  =  System-Specific  Applique.  The  component  of  the  general  purpose  TIS 
which  must  be  tailored  to  the  specific  characteristics  of  the  SUT. 

SUT  =  System  Under  Test.  Test  item,  usually  a  C3I  system,  to  be  exercised  by 
means  of  the  TIS. 

SYNC  =  Synchronization. 

TACFIRE  =  Tactical  Fire  Direction  system;  message  format  used  by  TACFIRE 

system  for  tactical  data  communications;  includes  TF-A,  TF-B,  and 
TF-C  subsets. 

TCS  =  Tactical  Computer  System.  A  TCS  is  a  minicomputer  which  may  act  as  a 
node  in  an  MCS  network.  A  TCS  will  support  multiple  analyst  consoles 
which  are  also  addressable  nodes  in  MCS. 

TCT  =  Tactical  Computer  Terminal.  A  TCT  is  a  microcomputer  which  may  act  as  a 
single  node  in  an  MCS  network. 

TDC  =  Time  dispersal  coding. 

TF-A,  B,  C  =  TACFIRE  interfaces;  type  A,  B,  and  C. 

TIS  =  Test  Item  Stimulator.  Successor  to  the  ITIS  system. 

TRN  =  Transmit  Repeat  Number.  Field  used  in  TACFIRE  messages. 
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USAEPG  =  U.S.  Army  Electronic  Proving  Ground 

VFMED  =  Variable-format  message-entry  device.  Part  of  TACFIRE. 


(BLANK  PAGE) 
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1.  Host  Interface  Unit  (HIU)  Fire  Direction  Center  (FDC)  Interfaces  Requirements. 
The  functional  interface  between  the  FDC  and  the  HIU  shall  take  place  over  the 
device  bus  of  the  FDC  AN/GYK-12  computer.  The  HIU  shall  emulate  those  electrical 
and  functional  characteristics  of  a  Digital  Data  Terminal  (DDT)  which  are  necessary 
to  facilitate  data  transfer  between  the  FDC  and  the  terminal.  In  this  appendix, 
the  AN/GYK-12  shall  be  referred  to  as  the  computer. 

1.1  Computer-to-HIU  Interface  Characteristics.  The  data  and  handshake  lines 
employed  in  the  computer-to-HlU  interface  shall  be  as  shown  in  figure  C-l. 


1.  Data  Signals.  Information  lines  1  through  7  shall  contain  the 
7-bit  ASCII  data  character.  Information  line  0  is  not  used  (set 
to  0)  for  ASCII  data  transfer;  information  line  P  shall  contain 
the  byte  odd  parity  bit.  A  single  character  is  transmitted  as  a 
result  of  a  data  transfer  sequence. 

2.  Address  Selection.  Eight  information  lines  shall  be  used  to 
indicate  which  communication  channel  is  being  selected.  A 
channel  is  selected  by  the  individual  channel  line  being  pulsed 
coincident  with  an  Enable  or  Command  signal.  The  HIU  is 
selected  when  information  line  0  or  1  is  pulsed. 

3.  Command  Control.  The  information  lines  shall  be  used  to 
signify  specific  operational  actions  to  be  performed  by  the  HIU, 
subsequent  to  the  address  selection  phase.  The  information 
appearing  on  the  information  lines  shall  specify  which  of  the 
operations  is  to  be  performed  (refer  to  table  C-I). 

b.  Request  Lines  (to  Computer).  The  communication  channel  shall  have 
eight  Request  lines,  with  two  Request  lines  assigned  to  each  circuit, 
one  line  for  transmit  (odd-numbered  Request  line)  and  one  line  for 
receive  (even-numbered  Request  lines).  Without  the  HIU  present  these 
lines  are  used  to  indicate  which  device  on  the  IOX  bus  is  requesting 
service,  and  whether  the  request  is  for  transmit  or  receive.  The  HIU 
shall  use  lines  0/1  to  indicate  to  the  computer  to  which  circuit  the 
message  being  transferred  is  associated.  (Table  C-II  shows  the 
relationship. ) 

c.  Enable  Line  (from  Computer).  This  signal  shall  be  used  in  conjunc¬ 
tion  with  the  information  lines  to  perform  address  selection.  When 
this  signal  appears,  the  following  transfer  of  information  shall  have 
data  flowing  to  or  from  the  computer,  or  it  shall  be  an  HIU 
interrupt.  This  signal  shall  also  be  used  in  conjunction  with  the 
Command  line  to  signify  a  Master  Reset. 

d.  Command  Line  (from  Computer).  This  signal  shall  be  used  in 
conjunction  with  the  information  lines  to  perform  address  selection. 
When  this  signal  appears,  the  following  transfer  of  information  shall 
be  a  command  operation  as  shown  in  table  C-I.  Further  information 
flow  shall  be  predicated  upon  the  actual  command  issued.  This  signal 
shall  also  be  used  in  conjunction  with  the  Enable  line  to  signify  a 
Master  Reset. 

e.  Indicator  Line  (to  Computer).  The  Indicator  line  shall  be  used  for 
two  purposes:  to  acknowledge  receipt  of  a  special  command  and  to 
initiate  a  device  interrupt. 

f.  Interlock.  The  Interlock  signal  shall  be  routed  through  the  HIU  to 
ensure  cable  connection  integrity. 

2.  I/O  Operations.  The  host  interface  unit  (HIU)  shall  support  the  command 
and  data  transfer  protocols  described  in  the  following  paragraphs. 

The  HIU  shall  not  support  the  following  computer  I/O  modes: 
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TABLE  C-I.  COMMAND  FORMAT  ON  INFORMATION  LINES 


BITS  PRESENT 

DURING  COMMAND  PHASE 

FUNCTION 

0  AND  3 

DEVICE  COMMAND  (DEV) 

0  AND  4 

OUTPUT  FROM  REGISTER  ( OFR)* 

0  AND  5 

INPUT  TO  REGISTER  (ITR) 

0  AND  6 

END  OF  BLOCK  (EOB) 

0  AND  7 

DEVICE  STOP 

*  NOT  USED  BY  HIU 


TABLE  C-I I.  REQUEST  LINE  ASSIGNMENTS  FOR  EACH  IOX 


CHANNEL  SELECT 

SWITCH  SETTING 

REQUEST  LINE 

RECEIVE 

- TRANSMIT 

0/1* 

0 

1 

2/3 

2 

3 

4/5 

4 

5 

6/7 

6 

7 

REMOTE' 

0 

0 

'  PERIPHERAL  EQUIPMENT  INTERFACE:  COMPUTER  NOT  CONNECTED  TO  INTERFACE 
COM  APP  LINES  SHORTED. 

*  HIU  NOT  FRONT  PANEL  SWITCH  SELECTABLE  HARDWIRED  TO  0/1. 


AO 


a.  Alarm  mode 


b.  Burst  mode 

2.1  Command  Recognition.  The  HIU  shall  recognize  that  a  command  sequence  is 
in  progress  by  sensing  a  signal  on  the  command  twisted-pair  signal  line  between 
the  computer  and  the  HIU. 

2.1.1  Command  Sequence.  The  timing  for  a  Command  Sequence  shall  be  as  shown 
in  figures  C-3  and  C-5  through  7.  Table  C-III  and  figure  C-2  define  the 
notations  used  in  the  timing  diagrams.  The  Command  Sequence  shall  consist  of 
the  following  operations: 

a.  The  HIU  senses  a  Command  signal  on  the  transmit  command  line. 

b.  The  HIU  shall  accept  the  address  character  on  the  eight  information 
lines. 

c.  If  the  parity  is  proper  and  the  control  character  is  a  true  control 
character,  the  HIU  shall  generate  an  acknowledgement  of  the  control 
sequence  by  generating  a  signal  on  the  Indicator  line  within  10 
microseconds  after  receipt  of  the  Device  Command  signal. 

2.1.2  Command  Operations.  The  HIU  shall  determine  the  particular  command  from 
the  computer  by  sensing  the  eight  information  lines  and  recognizing  the 
character  present.  The  commands  supported  shall  be  those  specified  in  table 
C-I  and  shall  be  present  on  the  eight  information  lines  in  conjunction  with  the 
Command  line. 

2.1.3  DEV  Operation.  The  DEV  command  consists  of  an  address  selection  phase, 
employing  the  Command  line,  a  device  control  phase  with  information  lines  0  and 
3  activated,  followed  by  a  single  byte  of  information  which  is  used  by  the  HIU 
for  control  purposes.  The  HIU  commands  are  defined  in  table  C-IV.  The  HIU 
shall  acknowledge  receipt  of  this  command  sequence  by  activating  the  indicator 
line  after  receiving  the  data  byte.  The  timing  for  this  command  sequence  is 
shown  in  figure  C-3.  If  the  HIU  is  commanded  to  enter  a  state  it  is  presently 
in,  the  HIU  shall  not  acknowledge  the  command. 

2.1.4  ITR  Operation.  The  Input-to-Register  (ITR)  sequence  consists  of  an 
address  selection  phase  employing  the  Command  line,  followed  by  a  device 
control  phase  employing  information  lines  0  and  5,  followed  by  one  data  byte 
generated  by  the  HIU.  The  contents  of  the  data  byte  shall  be  as  specified  in 
figure  C-4.  Timing  for  this  instruction  is  shown  in  figure  C-5. 

2.1.5  EOB  Operation.  The  End-of  Block  (EOB)  sequence  consists  of  an  address 
selection  phase  employing  the  Command  line,  followed  by  a  device  control  phase 
employing  information  lines  0  and  6.  If  the  HIU  is  to  interrupt  the  computer, 
it  may  send  a  Request  any  time  after  recognizing  the  device  control  informa¬ 
tion.  The  timing  for  this  sequence  is  shown  in  figure  C-6. 

2.1.6  Stop  Operation.  This  operational  sequence  consists  of  an  address 
selection  phase  employing  the  Command  line,  followed  by  a  device  control  phase 
employing  information  lines  0  and  7.  The  sequence  is  generated  by  the  computer 
when  an  illegal  or  erroneous  condition  occurs  as  related  to  the  HIU.  When  the 
HIU  detects  this  operation  is  shown  in  figure  C-7. 
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TABLE  C-III.  IOX  BUS  TIMING  PARAMETERS 


PARAMETER  REMARKS 

SYMBOL 

MIN 

TYP 

MAX 

UNIT 

HIU  RESPONSE,  CONTROL  WORD  ACK 

1 

tCA 

i 

5 

: 

MS 

COMPUTER  INTERVAL,  DATA  OUT 

too 

1.7 

3.0 

7.2 

MS 

HIU  REQUEST  TIMING 

tR 

0.4 

1.3 

MS 

COMPUTER  RESPONSE  TO  REQUEST 

tE 

0.240 

31 

MS 

(HIGHEST  PRIORITY) 

HIU  RESPONSE,  DATA  IN  EOB 

tQI 

0.4 

1 

5.0 

MS 

SEQUENCE  TIMING 

I:  HIU  TO  COMPUTER 

tEOB(I) 

6.3 

MS 

0:  COMPUTER  TO  HIU 

tEOB(O) 

1.3 

MS 

HIU  RESPONSE 

tlD 

0.57  | 

1.5  1 

MS 

HIU  RESPONSE,  INTERRUPT  REQUEST 

t£R 

1° 

1.5 

MS 

AFTER  EOB 

j 

1 

i 

1 

HIU  INTERRUPT  TIME  AFTER  ENABLE 

1 

0 

i 

1.5 

MS 

*  THE  SYMBOLS  ARE  DEFINED 
tCA  FIGURE  C-3 
tD0  FIGURE  C-8 
tR,  FIGURE  C-8 
tE,  FIGURE  C-8 


IN  THE  NOTED  FIGURES: 
t0I,  FIGURE  C-5 
t£OB»  FIGURE  C-7 
tID,  FIGURE  C-6 
tER,  FIGURE  C-6 
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TRANSMISSION  BY  THE  COMPUTER 

TRANSMISSION  BY  THE  HIU 

CHANNEL  ADDRESS 

CONTROL  WORD 

OR  GENERAL  DATA 


LiBiin*! 


92W''] 


TABLE  C-IV.  HI U  DEVICE  COMMANDS 


BINARY  CODE 

ASCII 

IF  RECEIVE 
CHANNEL 

IF  TRANSMIT  CHANNEL 

OOIOOIO 

DC2 

BEGIN  RECEIVING 

COMPUTER  INTERFACE  LOOP 

0  0  1  0  0  1  1 

DC3 

COMPUTER  INTERFACE  LOOP 

0  0  10  10  0 

DC4 

LOCAL  LOOP  TEST 

0  0  1  1  0  0  0 

CAN 

STOP  RECEIVING 

STOP  TRANSMITTING  PREAMBLE 

0  0  110  11 

ESC 

TRANSMIT,  CODED 

COMMAND 

INFORMATION 


INDICATOR  _ 

COMPUTER:  SELECT 


COMMAND 


HIM: 

TIMING  REF 


ACKNOWLEDGE 

1.2 


*  ALTHOUGH  tCA  IS  MEASURED  FROM  THE  LEADING  EDGE  OF  THE 
CONTROL  WORD,  THEHIU  MAY  NOT  TRANSMIT  ACKNOWLEDGE 
(INDICATOR)  UNTIL  AFTER  THE  TRAILING  EDGE  OF  THE  COMMAND 
IS  RESPONSE  TO  DEV 


Figure  C-3.  DEV  Operation  Timing 


HIU  IS  RECEIVING  A  MESSAGE 


6 

600  BAUD  OPERATION  (ALWAYS  "0"  FOR  HIU) 

5 

SINGLE  BLOCK  MODE  (ALWAYS  "1"  FOR  HIU) 

D 

CAN'T  TRANSMIT 

3 

A  KG  IS  ON  LINE  (ALWAYS  "0"  FOR  HIU) 

2 

Tx  BUSY 

1 

Rx  ERROR— RESPONSE  TIMEOUT 

0 

Tx  ERROR— RESPONSE  TIMEOUT  OR  PARITY  ERROR 

P 

PARITY  (ODD) 

COMMAND 


INFORMATION 

INDICATOR 


COMPUTER: 

HIU 


TIMING  REF 


Figure  C-6.  EOB  Sequence  Timing 


REQUEST 

ENABLE 


COMMAND 

INDICATOR 


INFORMATION 


2.2  Computer-to-HIU  Data  Transfer.  The  transfer  of  data  characters  from  the 
computer  to  the  HIU  shall  be  accomplished  as  described  herein,  and  as  shown  in 
figure  C-8.  Data  transfers  rate  shall  not  exceed  one  character  transfer  per 
250  microseconds. 

a.  The  HIU  shall  generate  a  Request  pulse  for  the  first  character. 

b.  The  HIU,  at  some  later  time,  shall  recognize  an  Enable  pulse  from 

the  computer. 

c.  Data  shall  be  present  on  the  information  lines  approximately  5 
microseconds  after  the  Enable  signal. 

d.  Steps  a  through  c  are  repeated  until  an  EOB  signal  is  sensed  by  the 
HIU,  as  shown  in  figure  C-6. 

2.3  HlU-to-Computer  Data  Transfer.  The  transfer  of  data  to  the  computer  shall 

be  accomplished  as  described  herein,  and  as  shown  in  figure  C-9.  The  transfer 
of  characters  shall  not  exceed  one  transfer  per  250  microseconds. 

a.  The  HIU  shall  generate  a  Request  pulse  for  the  character. 

b.  The  HIU,  at  some  later  time,  shall  recognize  an  Enable  pulse  with 

the  selected  address. 

c.  The  HIU  shall  then  place  the  character  on  the  data  lines. 

d.  Steps  a  through  c  are  repeated  until  the  HIU  has  passed  the  full 
message  to  the  computer. 

e.  After  the  full  message  is  transferred,  the  HIU  shall  transfer  an  EOT 
to  the  computer  using  sequences  a  through  d.  The  HIU  shall  then 
repeat  steps  a  and  b  and  then  transmit  a  pulse  to  the  computer  on  the 
indicator  line. 

f.  After  e,  the  HIU  shall  reset  to  receive  the  next  message. 

2.4  Master  Reset.  The  HIU  shall  perform  a  Master  Reset  when  the  Enable  and 
Command  signals  are  both  present. 

2.5  Interface  Signal  Characteristics.  Except  for  the  interlock  lines,  the  HIU 
shall  be  connected  to  the  computer  using  the  types  of  circuits  described  in  the 
following  subsections.  Figure  C-10  depicts  the  circuits  and  communication 
technique.  All  lines  shall  be  twisted-pair,  signal  and  return  lines.  Each 
signal  line  shall  be  terminated  by  an  82-ohm  resistor  at  the  end  of  the  remote 
line.  These  lines  shall  be  AC-coupled  at  the  HIU,  with  a  transformer. 

2.5.1  Current  Convention.  The  signal  currents  shall  be  conventional  currents, 
flowing  from  positive  to  negative  potentials.  A  positive  current  indicates 
that  the  circuit  is  supplying  current;  a  negative  current  indicates  that  the 
circuit  is  receiving  current. 

2.5. 1.1  Logic  Levels.  The  logic  levels  for  I/O  communication  shall  be  as 
follows : 
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* 


gure  C-10.  AC  Interface  Circuits 


a.  A  logical  1  shall  be  a  pulse  with  a  width  greater  than  120 
nanoseconds  and  an  amplitude  greater  than  3  volts. 

b.  A  logical  0  shall  be  a  signal  not  to  exceed  0.4  volts  or,  the 
communication  line. 

2.5.2  Mechanical  Interface.  The  signal  connector  used  to  interface  the  III 
with  the  computer  shall  be  a  55-pin  connector  as  specified  in  Litton  Speci¬ 
fication  586005-635.  Pin  assignments  shall  be  as  shown  in  table  C-V. 
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TABLE  C-V.  HIU-TO-COMPUTER  ( IOX)  INTERFACE  BUS 


|  SIGNAL 


INFORMATION  BIT  P 
Return 

INFORMATION  BIT  0 
Return 

INFORMATION  BIT  1 
Return 

INFORMATION  BIT  2 
Return 


I/O  CONNECTOR 
PIN  ASSIGNMENT 


A 

B 

C 

0 

E 

F 

G 

H 


SIGNAL 


REQUEST  5 
Return 

REQUEST  6 
Return 

REQUEST  7 
Return 


ENABLE 

Return 


I/O  CONNECTOR 
PIN  ASSIGNMENT 


f 

g 

h 

i 

1 

k 


m 

n 


INFORMAT  I  Oil  BIT  3 
Return 

INFORMATION  BIT  4 
Return 


J 

K 

L 

M 


COMMAND 

Return 


INDICATOR 

Return 


P 

q 

r 

s 


INFORMATION  BIT  5 
Return 


N 

P 


BURST 

Return 


t 

u 


INFORMATION  BIT  6 
Return 

INFORMATION  BIT  7 
Return 

REQUEST  0 
Return 


R 

S 

x 

u 

v 

w 


READY 

Return 


v 

w 


Spare 

Return 


x 

y 


Spare 

Return 


z 

AA 


REQUEST  1 
Return 

REQUEST  2 
Return 

REQUEST  3 
Return 


X 

Y 


Spare 

Return 


BB 

CC 


Z 

a 


COM  APP 
Return 


OD 


b 

c 


INTERLOCK 

(TERMINATOR) 


FF 


INTERLOCK 

(TERMINATOR) 


GG 


REQUEST  4 
Return 


d 


INTERLOCK 


HH 


e 


(CONNECTOR) 
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APPENDIX  D 

HAMMING  CODE  GENERATION 


When  transmitting  a  message,  five  Hamming  check  bits  are  generated  for 
each  7-bit  character  in  accordance  with  table  D-I.  The  X  bits  shown  in  the 
table  are  set  to  give  the  Y  bits  odd  parity.  The  characters  b.  through  b,  are 
the  data  bits,  and  P,  through  P5  are  the  Hamming  check  bits.  An  example  of  the 
generation  of  the  parity  for  the  ASCII  character  X  is  shown  in  table  D-I I . 

Hamming  code  bits  will  be  calculated  for  each  7-bit  character  in  the 
crypto  sync,  comm  line,  text,  checksum,  and  message  ending  field  of  a  received 
message,  except  that  the  value  of  the  calculated  bit  (P5)  will  be  based  on  the 
content  of  the  received  b.-b,  and  P--P . )  bits.  The  calculated  and  received 
Hamming  code  bits  will  beiexclusiveTy  OR'ed  to  form  a  5-bit  correction  word 
(see  table  D-I I I ) .  The  value  of  the  correction  word  as  specified  in  table 
D-I I I  indicates  whether  the  received  character  code  is  correct,  contains  a 
single  (correctable)  error,  or  contains  uncorrectable  errors. 


The  content  of  this  appendix  is  adapted  from  paragraphs  3.6. 1.3.1  -  3.6. 1.3.2 
of  reference  14  (see  appendix  F). 
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NOTE:  Pi  IS  ODD  PARITY  ON  THE  7  DATA  BITS 

P2  IS  ODD  PARITY  ON  DATA  BITS  1,  3,  5,  AND  7 

P3  IS  ODD  PARITY  ON  DATA  BITS  2,  3,  6,  AND  7 

P4  IS  ODD  PARITY  ON  DATA  BITS  4,  5,  6,  AND  7 

Rj  IS  ODD  PARITY  ON  DATA  BITS  1  THROUGH  7  AND  PARITY  BITS 

1  THROUGH  4 


TABLE  D- III.  PARITY  CHECK  CORRECTION  WORD 


P1 

CORRECTION 

WORD 

P  P  P  P 

2  3  4  5 

BIT  IN 
ERROR 

DECISION 

ACTION 

0 

0 

0 

0 

0 

NONE 

CORRECT 

ACCEPT  CHARACTER,  DISCARD 

PARITY  BITS 

1 

1 

0 

0 

1 

bi 

CORRECTABLE 

1 

1 

0 

1 

0 

1 

b2 

CORRECTABLE 

1 

1 

1 

0 

1 

b3 

CORRECTABLE 

REVERSE  STATE  OF  THE  BIT  IN  ERROR 

1(0  TO  1  OR  1  TO  0  AS  REQUIRED), 

1 

0 

0 

1 

1 

b4 

CORRECTABLE 

/ACCEPT  THE  RESULTANT  CHARACTER, 

AND  DISCARD  THE  PARITY  BITS 

1 

1 

0 

1 

1 

b5 

CORRECTABLE 

l 

0 

1 

1 

1 

b6 

CORRECTABLE 

1 

1 

1 

1 

1 

b7 

CORRECTABLE 

✓ 

1 

0 

0 

0 

1 

P1 

CORRECTABLE 

\ 

0 

1 

0 

0 

1 

P2 

CORRECTABLE 

PARITY  BIT  IN  ERROR;  ACCEPT 

0 

0 

i 

0 

1 

p3 

CORRECTABLE 

> CHARACTER ,  AND  DISCARD  PARITY 

BITS 

0 

0 

0 

1 

1 

P4 

CORRECTABLE 

0 

0 

0 

0 

1 

P5 

CORRECTABLE 

OTHER  VALUES 

UNC0RRECTA8LE 

DISCARD  ASSOCIATED  16-CHARACTER 

BLOCK  (EXCEPT  WITH  THE  RDT) 

bi  t>2  b3  b4  b5  b6  b7  P1  p2  p3  p4  p5 


RECEIVED  CHARACTER  AND  PARITY  100011010110 
CALCULATED  PARITY  01011 
CORRECTION  WORD  11101 
CORRECTED  BIT  -  b3 
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1.  TACFIRE  Message  Formats.  TACFIRE  messages  are  composed  of  7-bit  ASCII 
characters.  The  fixed  and  variable  format  messages  are  shown  in  figure  E-l  and 
E-2.  Format  of  the  message  fields  is  described  in  the  following: 

1.1  Message  Header.  The  definition  of  the  header  characters  is  as  follows: 

a.  Character  1  shall  indicate  the  destination  of  the  message.  The 
allowable  character  set  is  0-9  and  A-Z. 

b.  Character  2  is  a  transmission  repeat  character.  This  character  can 
have  the  values  0-3. 

c.  Characters  3  and  4  provide  a  serialization/authentication 
capability.  The  allowable  character  set  is  0-9  and  A-Z. 

d.  Character  5  indicates  whether  the  message  will  be  a  normal  or  test 
message.  The  character  "D"  identifies  normal  data,  the  character  "T" 
identifies  a  test  message. 

e.  Character  6  provides  device  identification.  The  allowable  character 
set  is  0-9  and  A-Z. 

f.  Character  7  defines  the  message  format  (delimiter). 

1.2  Communications  Line  Header.  The  definition  of  the  communications  line 
header  fields  is  as  follows: 


a.  Priority  (P).  The  message  priority  is  determined  from  the  message 
category  and  type.  If  not  specified  by  the  FDC  operator,  the 
priority  is  assigned  by  the  computer.  The  priorities  range  from  one 
(highest)  to  seven  (lowest). 

b.  Subscriber  (SB).  The  subscriber  is  the  logical  name  either  of  the 
recipient  or  the  originator  of  the  message  and  is  the  logical 
subscriber  name  in  the  SYS; SBT  message. 


c.  Security  Classification  (C).  The  security  classification  field 

identifies  the  security  level  of  the  message  text.  The  field  shall 
contain  one  of  the  following  entries: 


Character  Meaning 


UN 

ETO 

C 

S 

C 

SRD 

C*C 

S#C 


Unc .assified 

Encrypt  for  transmission  only 

Confidential 

Secret 

Confidential  formerly  restricted  data 
Secret  restricted  data 
Confidential  crypto 
Secret  crypto 


The  content  of  this  appendix  is  derived  from  appendix  IV  of  reference  19  (see 
appendix  F). 


CHARACTER  1234567  8  TO  44 


FREE  TEXT  UP  TO  36  CHARACTERS;  FIXED 
FIXED  FORMAT  25,  27,  OR  36  CHARACTERS 


Figure  E-l.  TACFIRE  Message  Fixed  Format  (TF-C) 
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d.  Segment  Information  (SG).  The  segment  information  shall  occupy 
spaces  34  through  42.  Spaces  37  and  38  indicate  the  message  segment; 
spaces  40  and  41,  the  total  number  of  segments.  For  example:  SG : 3- ; 
10  means  that  this  message  segment  is  the  third  of  10.  If  the  field 
is  not  specified,  one  segment  shall  be  assumed.  A  message  segment 
shall  be  determined  by  an  alphanumeric  sequence  ending  with  the 
end-of-text  (EOT)  symbol.  Error  messages  linked  to  a  message  shall 
be  segment  0  in  the  comm  line  (0  of  1),  and  the  message  shall  be 
segment  1  of  1. 

e.  Date  Time  (DT).  The  DT  occupies  spaces  43  through  57  of  the  comm 
line.  The  computer  inserts  the  system  date  and  relay  time  when  the 
message  is  received  by  the  FDC  and  when  the  FDC  operator  takes 
transmit  or  computer  action  on  a  message.  On  a  net  monitor  error 
message,  the  comm  line  is  not  modified.  Spaces  46  and  47  shall 
indicate  the  day,  1  through  31;  spaces  49  and  50  specify  the  hour,  0 
through  23;  spaces  52  and  53,  the  minutes  0  through  59;  and  spaces  55 
and  56,  the  seconds  0  through  59. 

f.  Messages  Identification  Number  (ID).  This  is  a  unique  serial 
identification  number  assigned  by  the  message  processing  system. 

This  field  occupies  spaces  58  through  65,  message  ID  0000-9999. 

g.  Automatic  Transmission  (A).  This  field  occupies  spaces  66  through 
69.  The  initial  setting  of  this  field  shall  be  blank.  If  automatic 
transmission  is  used,  the  FDC  computer  will  insert  the  character  A  in 
space  68.  The  operator  directs  that  an  unencrypted  classified 
message  (except  for  crypto  classification)  be  transmitted  in  the 
clear  by  inserting  the  letter  0  in  space  68. 

h.  HIU.  Space  70  is  used  to  indicate  the  HIU  received  the  message.  The 
HIU  number  is  supplied  by  the  computer. 

1.3  Example  Formats.  Tables  E-I  and  E-II  illustrate  two  possible  message 
formats  in  the  TACFlRE-  message  set.  Note  that  these  are  both  TF-A  variable 
formats.  The  first  line  of  each  of  these  two  message  formats  corresponds  to 
the  header  information  illustrated  in  figure  E-2. 
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TABLE  E-I.  SYS  MISCELLANEOUS  INPUT  MESSAGE  FORMAT 


;P  :  ;SB :  I  I  I  I  ; C :  UN  ;SG:_,  ; DT :  . _ /  / _ ;ID: _ ;A:_; 

S'yT-mTSCjPR  I  NT :  0 ;  SPR 1 : 0  ;  MDS770_;  LLP  I :  (T;  RLP I : 0_;  CFTO  F  S :  0 _ ; 

SPR:0;PACK:a;REST:0;0ELT£S:0  ;DATE:0  /  /  ;TIME:0  /  /  ; DELOFF :_0 ; 

STAT  :0;NETMDE  :0/  /  .  ; DELAY :  0  /  /  /  ; D I V :  0 ;  MPL I  ST :  0 ;  REPORT  :_0 ; 

PAL  L :  0 ;  P  RD :  0 ;  P  CEO :  0 ;  P  E  TD :  0 ;  P  DP  M :  0 ;  P  D  DT7073/_/_/_/_/_;  P  E  L  P :  0 ; 
PCMU:0/_/_/_/_/_/  ;PCP  U:0  ;MODE :  0 _ ;MFREX:J;CCU:Q  j 

Purpose:  To  enter  miscellaneous  data 

TABLE  E-I  I.  SYS  MDS  INPUT  MESSAGE  FORMAT 


_ ;  P SB / 

SYS;MDS;MSEL:0_;KGFD:0_/ 

LLOOP : 0 _ / 

RLOOP :  0 _ / 

VFMEDiO  / 

TFDMD:0_/ 

DIVBNrO  / 


;C : UN  ;SG: 
";BDUFI:0  /' 


;DT: 


/  /  ; I D: 


;A: 


;BDULP:0  / 

ELP1D: 0  / 

DDTAD:0  / 

DDTFD-.O  / 

ELP1I :0  / 

;CPUFD:0  / 
;CMUFD:0  / 
;ARM1D:0  / 
;ARM2D:0  / 

ELP2D: 0  / 
ACCFD: 0  / 
DPMFD'.O  / 
ETDFD:0  / 

DDTBD: 0  / 
DDTCD:0  / 
OOTDDiO  / 
DOTED :0  / 

DDTGD:0  / 
DDTHD.-O  / 

armii-.TT/ 

ARM2I :C  / 

ELP2I :C  / 
ACCFI :0  / 
DPMFI :0  / 
ETDFI :C  /  j 

Purpose:  To  initiate  or  end  maintenance  and  diagnostic  (M&D)  tests 
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